Grupo 8

En este documento vamos a encontrar el feedback recibido por el grupo 8

---

Semana 1

Feedback alumnos

• ¿Plan de precios para los usuarios y para las empresas?
• En cuanto al análisis de competidores. Posibilidad de incluir competidores de contratación de catering
• Competencia con instagram -> caterings que utilizan instagram para realizar las contrataciones.
• Realizar un estudio en cuanto al tema de suscripciones a la aplicación. Definir quién paga.

Feedback profesores

• Definir claramente el alcance
• Definir de manera correcta los tipos de cliente
• Idea -> Evitar el tipo de suscripciones por parte del usuario y realizar un cobro por parte de banquetbuddy al sueldo total obtenido por la persona.
• Otro tipo de cliente: ¿Quién suministra materiales a los caterings?
• Fuente utilizada en la presentación.
• Roles: Todos tienen que tener rol de desarrollador.
• No ser tan específicos con los costes en las presentaciones -> Dejar eso para la entrega de documentos.
• ¿Cómo se ha llegado a los competidores?

Semana 2

Feedback profesores

• Olvidarse de lo que se ha hecho la semana pasada,presentar como si la audiencia no hubiese oído nunca de la aplicación
• Buen killer opener,pero pensar en algo que conecte con la audiencia
• Más información sobre análisis de competidores,como hemos llegado a ese análisis
• En usuarios pilotos poner más gente que gestione catering
• No están contemplados los costes de las herramientas de desarrollo dentro del TCO
• Tener en cuenta los usuarios que no pagan
• Comentar algo sobre los prompts de IA usados
• Commitment Agreement: Incluirlo en la presentación los cambios realizados y si se esta cumpliendo

Semana 3

Feedback profesores

• Meter cláusulas de confidencialidad (-customer agreement?)
• Distinguir entre proyecto y servicio(proyectos puede haber mucho dentro de un servicio)
• Meter fotos más presentables
• Especificar cómo estamos usando las métricas para medir el rendimiento
• Buen inicio efectivo,pero se ha perdido ese hilo conductual a medida que ha ido desarrollandose la presentación
• Estrategias de gestión de la documentación como código
• Crear una rama para la documentación
• No decir echar horas,mejorar el vocabulario
• Practicar la presentación delante de todo el equipo,así se puede dar feedback antes de la presentación oficial
• Documentar bien los cambios que se van haciendo y proyectarlo en la presentación
• Intentar no ponerse delante de la pantalla de la presentación
• Autodefensa al final de la presentación

Semana 4

Feedback profesores

• Usuarios pilotos ¿Deberíamos aumentar el rango de edad?
• TCO, muy escueto. Especificar un poco más. Decir para cuantos usuarios es el presupuesto PARA EL PRÓXIMO DIA HAY QUE VERLO.
• Análisis de riesgos -> PONERLO EN LA PRESENTACIÓN
• En la tabla de rendimiento deberíamos añadir indicadores si el rendimiento esta subiendo o bajando
• Deberíamos añadir métricas de rendimiento, sintetizar la información en una gráfica/tabla. Una única transparencia con el rendimiento individual y cómo ha evolucionado de una semana a otra
• Añadir comparativa de rendimiento de cada uno a lo largo de las semanas
• Expresiones más neutras(utilizar palabras menos negativas), las medidas se adaptan en función de lo que se necesite.
• Simplificar documentos, 105 documentos es demasiado. Portfolio de la documentación (docusaurus).. Estructura lógica de no más de 8-9 elementos de primer nivel. Pensar en el árbol de conocimiento (IMPORTANTE). Es mejor que la wiki de github.
• Herramientas de markdown para poder colaborar en el mismo tiempo.
• Muy buena gestión de los usuarios pilotos, vision temporal en 2 semanas
• Customer agreement muy bueno.
• Killer opener, innovar una posible idea es decir de donde eres, para que empaticen(compartir algo personal para que la gente empatice contigo es una buena técnica)

Semana 5

Feedback profesores

• Incluir situación actual,incluyendo casos pesimistas,optimistas y neutras
• Estado del commitment agreement,poner cuánto se ha cumplido
• Funcionalidades escasas de la aplicación,incluir algunas más de valor
• Poner el número de usuarios pilotos de los que disponemos
• Buscar más usuarios pilotos
• Especificar que partes de funcionalidad vamos a implementar en cada sprint en la aplicación
• Poner precio/mes en vez de precio/año
• Pensar en los que van a corregir a la hora de hacer la presentación

Semana 7

Feedback profesores

• Los costes nunca pueden alcanzar cero,ya que hay que tener en cuenta las licencias y otros costes de operación
• Especificar de donde sale el número de clientes que se ha tenido en cuenta para hacer la estimación de costes y beneficios(intentar fijarse en el flujo de otros + competidores si queremos partir de datos realistas)
• Acercar la visión en la DEMO, tiene que verse bien al fondo (usar algún tipo de lupa o similar)
• Incluir más detalles de los riesgos,en que estados están y lecciones aprendidas
• Plantear fechas más tempranas para que los usuarios pilotos puedan probar las funcionalidades antes de las entregas
• Métricas de rendimiento.
• Hacer como un dashboard del rendimiento frente al esfuerzo incluyendo la información de cada miembro del grupo(de forma anónima)( Usando google charts dinámicos) teniendo 4 cuadrantes siendo el mejor el superior derecho
• Plantear plan de contingencia en caso de que los usuarios piloto quieran probar la aplicación
• Ha habido negociación con los usuarios pilotos? tenerlo en cuenta
• Probar darle a chatGPT el agreement de forma que no haya cláusulas abusivas
• Se podría plantear como se puede reutilizar la planificación entre sprints?
• Cómo vamos a abordar la issues mas grandes?intentar incluir milestones(ya lo tenemos)
• Incluir caras en el perfil de github
• A la hora de incluir la huella de carbono,pensar en el tamaño de la conversación también

Semana 8

• Colores muy similares en la gráfica de costes(se sugirió aumentar el grosor y distinguirlos un poco más)
• Mejorar la interfaz de usuario de la aplicación
• Incrementos sobre la versión previa(changelog debería ponerse antes de la demo)
• Aumentar tamaño letra en algunas diapositivas (Real Status(pag47), etc..)
• Buena evaluación de la IA
• Intentar usar más copilot
• Killer opener debería impactar, empezar con algo de más de chispa
• Hablar solamente capex y opex en la parte de TCO
• Hacer descripción al principio de la demo de lo que se va a enseñar
• Poner un icono de la persona que está logueada en la demo,para saber quien la está usando
• Hacer zoom en momentos puntuales,puede marear a la audiencia y podría ocultar zonas relevantes
• No incluir diapositivas si no se habla de ellas
• Que pasa cuando no se cumple el acuerdo con los usuarios piloto.

Semana 9

• Gastos de formación pertenece a capex,pero hay costes repercutidos para opex
• Aumentar tamaño de letra para leyenda (gráfica de costes)
• Opex no debería ser el mismo en los tres casos,ya que hay que tener en cuenta más infraestructura para mantener ese número de usuarios(va variando) (parte de coste pesimista / optimista / real)
• Mejorar los términos del testing procedure(model test son test de integración con base de datos),recomendación:meter pruebas de rendimiento con gatling,ver cuántos créditos se pueden consumir si atacan por ejemplo 5 personas
• La creación de platos no debería crearse directamente desde el perfil de usuario
• Concatenar el inicio efectivo con la historia de la DEMO
• Poner foto en la demo de quien es el usuario que está usando la aplicación
• Mejorar el ranking de gestión de feedback de usuarios (se pasó en la presentación comentar lo puesto en el guión)
• En la gráfica de rendimiento vs esfuerzo,rendimiento no debería ser puntos de historia ltx studio→para convertir storyboards en anuncios
• Reportar si los tests están siendo útiles,cuántos bugs se han detectado con estos
• Incluir objetivos que se pretenden alcanzar con las mediciones de los riesgos
• Apuntar en los costes, la api de correo.
• Traer altavoz para la próxima

Semana 10

• Hacer Killer opener bastante más visual
• Riesgos :objetivos,medidas y calidad de la solución adoptada
• Hacer el anuncio más grande en la presentación
• Agilizar el relleno de formularios en la DEMO y MAS ENERGIA.
• Gráfica de uso de la IA bien desarrollado
• Incluir qué cosas de implementación y testing va a llevarse a cabo en las siguientes semanas (si lo hay) en la planificación

Semana 11

• No utilizar vocabulario especializado (Matchmaking, CAPEX, OPEX,B2C Y B2B)
• Acercar la parte del portátil en los 2 anuncios
• No se oye bien por los altavoces de clase(no se llega a entender nada y presencia de eco)
• Demasiado texto en la transparencia de la segmentación de mercado,hacerlo más visuales
• Intentar buscar influencers que se enfoquen en la búsqueda de empleo joven
• La intro no queda muy clara, podemos adelantar el anuncio para que se entienda mejor
• Dejar claro que hace exactamente nuestra aplicación en el elevator pitch
• Quitar la parte de las funcionalidades específicas de cada usuario.
• DEMO seguir una historia mejor hilada, concretar unas funcionalidades .
• Hacer el final de la demostración menos abrupta.
• Centrarse más en las funcionalidades por las que se va a pagar. Si se quieren mostrar más funcionalidades mostrar una imagen después de la DEMO.
• Decidir el mensaje que se quiere transmitir en cada transparencia
• Destacar las funcionalidades clave que nos diferencian de nuestros competidores
• Decir mil en vez de K.
• La gráfica de costes vs beneficios se podría incluir en el anuncio de inversores
• En el anuncio de inversores faltan datos y estimaciones.
• Campaña de lanzamiento demasiado genérica,pensar que vamos a hacer nosotros en concreto para alcanzar a nuestro nicho de mercado
• SEGUNDA PARTE DE LA PRESENTACIÓN (CORTA):
• Poner algunos ejemplos de keyword directamente en el SEO
• Ejemplo de persona en los tipos de usuario
• Mencionar las redes sociales
• Separar facebook para gente mas mayor, gerentes y insta para mas jovenes
• Mirar cuanto cuesta influencers, anuncios de pago, etc…
• INCLUIR PERFILES DE CLIENTES

Semana 12

• En la demo se podrían pulir algunos puntos, como quitar formularios, etc,...
• Evitar describir la estructura de equipo en la presentación (sacamos foto común en la retro)
• Detallar de donde se saca el estudio de mercado?
• Solo hablar en la presentación cosas que aporten a responder las preguntas que nos dieron.(regla del algodón) (las preguntas de la estructura de presentación que nos dieron hace 2 semanas)
• Página 23 demasiada información
• Poner más datos económicos en el anuncio de inversores,qué obtienes al invertir en la aplicación.(como el grupo de shar3d y contar de eso de manera atractiva, no “técnica” que aburre)
• Indicar necesidades en los perfiles de clientes(en campaña de lanzamiento)
• Evitar anglicismos(targetear y etc)